home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 2: CDPD 1
/
Almathera Ten on Ten - Disc 2: CDPD 1.iso
/
pd
/
051-075
/
055
/
pipedevice
/
poster
< prev
Wrap
Text File
|
1995-03-13
|
3KB
|
65 lines
Article 1977 of comp.sys.amiga:
Path: mcdsun!noao!hao!hplabs!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: PIPE: device (1.2 only) *******
Message-ID: <8702062012.AA14465@cory.Berkeley.EDU>
Date: 6 Feb 87 20:12:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 608
Here's a PIPE device. I would like to thank Phillip Lindsay
for providing the skeleton device driver which I used as a base. This
will ONLY WORK WITH 1.2!!. Example (run all at once):
CLI window 1: copy hugefile pipe:a
CLI window 2: copy pipe:a pipe:b
CLI window 3: copy pipe:b pipe:c
CLI window 4: copy pipe:c pipe:d
CLI window 5: copy pipe:d pipe:e
CLI window 6: wordcount pipe:e (or something similar)
You can, of course, use any rendezvous name you wish. The device
uses a 4K internal buffer per name, but is optimized to take advantage of
the situation in which there is a pending read and a pending write. In this
case it copies direct rather than go through its internal buffer. This is
a true pipe, and thus the source and destination processes must be distinct
(i.e. not the same process) so as to prevent lockout situations. The buffer
is transparent in that data written, no matter how little, is immediately
available to be read by the other process.
You must place PIPE.DEVICE in 'DEVS:'. Append the MOUNTLIST file to
DEVS:MOUNTLIST (or just put it there if you do not have a DEVS:MOUNTLIST),
and then do a 'MOUNT PIPE:' in your startup script.
The source is provided also. Remember, since this is a device, you
do NOT link with any startup module. I have done a couple of other tests
and have found that you get a huge efficiency increase when piping an IO
bound program through a CPU bound program or vise versa. This is totally
public domain except for MISC.C, which is (C) to Phillip (but redistributable).
The binary itself is totally public domain.
USES:
I hope to have my shell use the PIPE: device in it's next release,
but this will require huge modifications to the shell so don't expect the
next release anytime soon.
Apart from that, the PIPE: device can be useful when you have, say, two
application programs and want to transfer huge amounts of data from one
(write) to the other (read) without using a temporary file in RAM: or on
disk. Assuming the application does not attempt a Seek(), you simply
specify 'PIPE:name' and it looks like an ordinary file to the application.
For those terminal programs which do not use asyncronous writes, you can
fix the jerkyness in CAPTURE by capturing to a pipe, and having another
CLI Copy command running from the pipe to a file.
Have fun and report any bugs to me,
-Matt